What is distinctive about how a data association is displayed in the diagram compared to the actual link behind it is described below. Automatic transfer of properties of a data element to an element to be linked is also described.
According to the BPMN specification, data associations can only connect data elements and always need to have an activity or event as the owner. When visualized, the edge always runs between the owner activity and, on the other side, the data element.
If you drag (create or transfer) an edge from a data element to a task/event, the edge is assigned to the task/event and a hidden data input is created as the edge’s target on the task/event. The data association looks like it is directly linked with the task/event in the diagram as the edge’s actual target is hidden.Vice versa, if you drag an edge from a task/event to a data element, the same happens as described above with the difference that a hidden data output is created for the task/event.
If you drag (create or transfer) an edge from a data element to a subprocess, the edge is assigned to the subprocess and a data input is created as the edge’s target in the subprocess but is not graphically linked to it. This is why the data association looks like it is directly linked with the subprocess in the diagram. Vice versa, if you drag an edge from a subprocess to a data element, the same happens as described above with the difference that a DataOutput is created for the subprocess.
Pull an edge between a data element and an activity/event using the carousel to create a data association. Depending on whether the activity/event is the association’s target or source, a data input or data output is implicitly created on the activity/event. This data element is visible in subprocesses but not for tasks/events. You can always see the data element as the activity/event of the subelement in the model browser. The new data input/output is given the same name as the data element the other side of the association. However, if necessary, this name is modified so that it is unique in the namespace of the activity/event. The data association is then created between both data elements.
You can only reconnect the source or target side of a data association to an element of the same element class in the diagram, i.e. either between activity/event nodes of a data element to another.
Changing a data association side to a new activity/event initially implicates a change of the data association’s owner. You also need a data input/output on the activity/event to be able to internally link the data association. To get this data element, a free, suitable data input/output is initially looked for on the target activity/event.The data element is suitable if its name and assigned term definition (BPItemDefinition) and element class (data input/output) correspond to the data element which is currently linked. An element is free if it is not yet linked with any data association. If no free and suitable data element is found, an appropriate element needs to be created, as was the case with creating described above. Properties of the output element need to be transferred to the new element. This affects the name, the linked term definition and any states assigned.
If you delete a data association, the data inputs/outputs assigned to it are also removed in the tasks and event if that is their only relationship, i.e. they cannot be linked to any other data associations or, in the case of CallActivities (task with the 'Call Activity' task type), cannot reference any data inputs/outputs of the called element.
If data inputs/outputs are created or deleted by the mechanism described above, this may mean that other maintenance actions are required regarding call activities and their called elements.
Innovator X Generation 11 R4 - Copyright © 2011-2012 - MID GmbH Nuremberg - DIN EN 9001 certified - All rights reserved.